A software defined networking (SDN) is a relatively new type of networking architecture that provides centralized management of network elements rather than a distributed architecture utilized by conventional networks. That is, in a distributed architecture each network element makes a routing, switching, and similar, decisions based on the results of traffic processing and a distributed control mechanism. In contrast, in the SDN, a network element follows routing (or switching), decisions received from a central controller.
In detail, the operation of a network element can be logically divided into a “control path” and a “data path”. In the control path, control protocols, e.g., for building in routing protocols, a spanning tree, and so on, are operable. In the data path, packets-processing operations are performed on a per-packet basis. Such operations include examining each incoming packet and making decisions based on the examination as to how to handle the input packet (e.g., packet forwarding, packet switching, bridging, load balancing, and so on). Furthermore, in a conventional network, network elements typically include both the control and data planes, whereas in a native SDN, the network elements include the data path, and the central controller implements the control path.
The SDN can be implemented in wide area networks (WANs), local area networks (LANs), the Internet, metropolitan area networks (MANs), ISP backbones, datacenters, inter-datacenter networks, and the like. Each network element in the SDN may be a router, a switch, a bridge, a load balancer, and so on, as well as any virtual instantiations thereof.
In one configuration of a SDN, the central controller communicates with the network elements using an OpenFlow protocol. Specifically, the OpenFlow protocol allows adding programmability to network elements for the purpose of packets-processing operations under the control of the central controller, thereby allowing the central controller to dynamically define the traffic handling decisions in the network element. To this end, traffic received by a network element that supports the OpenFlow protocol is processed and forwarded according to a set of rules defined by the central controller.
Traffic received by a network element that supports the OpenFlow is processed and routed according to a set of rules defined by the central controller based on the characteristic of the required network operation. Such a network element routes traffic according to, for example, a flow table and occasionally sends packets to the central controller. Each network element is programmed with a flow table and can be modified by the central controller as required. The operation of network elements and the definition of flow tables according to the OpenFlow protocol is further described in the Open Flow Switch Specification issued by the Open Networking Foundation.
While the OpenFlow protocol allows programmability of network elements in the SDN, such means does not define how this capability can be utilized to efficiently provide value added services including, but not limited to, security services to users of the SDN.
In many instances of traffic processing for the purpose of service insertion, traffic should be diverted, or steered, from its original path to be processed by a chain of servers (other than the destination server) and after such processing be relayed (or injected) back to the network to their original destination. However, conventional solutions for traffic steering have a few limitations including, for example, relatively complicated diversion operations, because traffic diversion relies on dedicated border gateway protocol (BGP) announcements issued by special devices in the network, and loop tendency, because the conventional solutions for traffic injection can cause infinite packet loops. Furthermore, such configuration is generally cumbersome and may result in non-optimized paths and inefficient utilization of computing resources in routers (e.g., CPU time of routers). In addition, diversion of traffic to a chain of servers which are remote from each other, i.e., spread across the network, is even more difficult to implement using existing traditional networks.
Other conventional solutions for redirecting traffic include proxy or transparent proxy servers or network devices. Such network devices add more complexity into the network as they need to be deployed in line, creating an additional point of failure in the network.
Therefore, it would be advantageous to provide a solution for simple and efficient traffic diversion in the SDN for at least providing value added services.